Background: There have been several reports from DoD users about DoD certificate issues recently. The root of the issue is associate with DoD Root certificates chaining improperly to the (Federal Government) Common Policy Root Certificate Authority (CA). When this occurs on DoD systems, PKI validation does not work properly and may result in any of the following: 1. DoD user denied access to DoD web sites. 2. DoD users are unable to access DREN VPNs. 3. DoD signed emails in outlook appear invalid. 4. DoD users experience extensive delays with Outlook or Internet Explorer during validation. 5. DoD users receive a prompt to install the Common Policy Root CA when opening a signed email of a DoD sender whose workstation is misconfigured. . Issue: On November 23, 2009, Microsoft released an update KB931125 which updated the third-party certification authorities (CAs) that are trusted by Microsoft and whose root certificates are distributed via the Windows Root Certificate Program. The following certificates are the root cause: Thumbprint: dc92f91bab283472023b32178504e19bf7d9a94c Issuer/Subject: Iss: OU=Entrust, OU=FBCA Sub: OU=Entrust, OU=FBCA Thumbprint: 0a0e46657f4148df2d1c6778ea9308a8ca41989f Issuer/Subject: Iss: CN=Common Policy, OU=FBCA Sub: OU=Entrust, OU=FBCA Thumbprint: 3bae7b920ee6616755be4fa287777eef2f6b33f6 Issuer/Subject: Iss: CN=Common Policy, OU=FBCA Sub: OU=Entrust, OU=FBCA Thumbprint: dc92f91bab283472023b32178504e19bf7d9a94c Issuer/Subject: Iss: OU=Entrust, OU=FBCA Sub: CN=DoD Interoperability Root CA 1 Thumbprint: eea68fc8701e41e6429a341ae4162bbda634f7f4 Issuer/Subject: Iss: CN=DoD Interoperability Root CA 1 Sub: CN=DoD Root CA 2 Steps Taken so far: Step 1: DoD Administrators with workstations affected by this issue should decline all KB931125 updates in Windows Server Update Services 3.0. From the WSUS 3.0 manager console, search for " 931125". Right click the update and select Decline for all updates related to 931125. Step 2: DoD Administrators with workstations affected by this issue should remove the certificates below either with the DoD PKE tool or some other means. The DoD PKE "FBCA Cross-Certificate Removal Tool" is available from the following location: PKE on DKO: https://www.us.army.mil/suite/page/474113 under "Downloads" The following cross-certificates should be removed from the Local Computer and User Intermediate Certification Authority store: (DISA PKE Support) Common Policy Entrust (FBCA) cross-certificate Subject: OU=FBCA, OU=FBCA,O=U.S. Government,C=us Issuer: OU=Common Policy,OU=FBCA,O=U.S. Government,C=us Serial # 18 cc d6 6b 00 01 00 00 00 6f Valid To: Thursday, April 23, 2015 9:20:26 AM Common Policy Entrust (FBCA) cross-certificate (Revoked) Subject: OU=FBCA, OU=FBCA,O=U.S. Government,C=us Issuer: OU=Common Policy,OU=FBCA,O=U.S. Government,C=us Serial # 62 fa 21 6f 00 01 00 00 00 56 Valid To: Friday, March 21, 2014 12:25:49 PM Entrust (FBCA) IRCA cross-certificate Subject: CN=DoD Interoperability Root CA 1,OU=PKI,OU=DoD,O=U.S. Government,C=US Issuer: OU=Entrust,OU=FBCA,O=U.S. Government,C=US Serial # 45 1d e5 23 Valid To: Friday, December 31, 2010 12:00:00 AM IRCA DoD Root CA 2 cross-certificate Subject: CN=DoD Root CA 2, OU=PKI,OU=DoD,O=U.S. Government,C=US Issuer: CN=DoD Interoperability Root CA 1,OU=PKI,OU=DoD,O=U.S. Government,C=US Serial # 0C Valid To: Thursday, March 03, 2011 10:22:43 AM The following self-signed certificate(s) should be removed from the Local Computer and User Trusted Root Certification Authority store: Entrust (FBCA) self-signed certificate Subject: OU=Entrust,OU=FBCA,O=U.S. Government,C=US Issuer: OU=Entrust,OU=FBCA,O=U.S. Government,C=US Serial # 45 1d e1 72 (DISA PKE Support) For Domain Administrators , the tool can run on domain workstations using a Group Policy Startup script. First, a hidden share should be configured on a server to capture logs that the script was run. The hidden share should allow everyone to write to the share, checking both NTFS and Share permissions. In this example, the share was called "FBCA-log$". Create another shared folder called "FBCA_Crosscert_fix" with read-only permissions for all users. Next, create a new Group Policy Object named " Configuration: Remove CommonPolicy CA Script", the group policy should be applied to the entire domain to ensure the misconfigured Root CA certs are completely removed from the domain. Next, create a new Startup script named " FBCA-scriptremove.cmd" with the following scripts. @echo off IF EXIST \\servername\FBCA-log$\%computername%.txt goto end \\servername\FBCA_Crosscert_fix\FBCA_crosscert_remover_v104.exe /commonpolicy /s > \\servername\FBCA-log$\%computername%.txt :end Next, download the DoD PKE Cert Removal tool from: https://www.us.army.mil/suite/page/474113 and place FBCA_crosscert_remover_v104.exe in the \\servername\FBCA_Crosscert_fix\ share. Lastly, ensure that the " Turn off Automatic Root Certificates Update" setting is "Enabled" in Group Policy on the domain. This setting can be set under: Computer Configuration | Administrative Templates | System | Internet Communication Management | Internet Communication settings. Step 2a: Additional Requirement for Windows XP SP2 workstations In some cases, it has been reported the " Turn off Automatic Root Certificates Update" GPO setting does not stop Windows from updating the Root Certificates automatically. Two additional steps must be taken. First, the " FBCA-scriptremove.cmd" script must be modified to include code to uninstall the "Update Root Certificates" Windows component installed under Windows XP SP2 by default. The script should now look like this: The script should now look like this: @echo off IF EXIST \\servername\FBCA-log$\%computername%.txt goto end \\servername\FBCA_Crosscert_fix\FBCA_crosscert_remover_v104.exe /commonpolicy /s > \\servername\FBCA-log$\%computername%.txt :end IF EXIST \\ servername \FBCA-log$\%computername%_WXP-03-Uninst-Updt-Rt-Cert-Comp.txt goto end sysocmgr /i:%windir%\inf\sysoc.inf /u:\\servername\software\FBCA_Crosscert_fix\rootautoupdateuninstall.txt /q > \\ servername \FBCA-log$\%computername%_WXP-03-Uninst-Updt-Rt-Cert-Comp.txt :end In addition, the following text file named " rootautoupdateuninstall.txt" should be created, located in the same share that was created to store the FBCA_crosscert_remover_v104.exe utility. For example: \\servername\FBCA_Crosscert_fix\ " rootautoupdateuninstall.txt" should contain the following text. [components] rootautoupdate = off Validation: If everything is setup and working correctly, when hosts restart, they will run the script one time, and write two log files to the \\servername\FBCA-log$\ share. The first file will be named after the host. The file will contain a log of the results of the FBCA_crosscert_remover_v104.exe utility. The log will contain one of two outcomes. No certs were found: ##### FBCA cross-certificate removal tool ##### Created by DoD PKE Engineering January 2010 BACKGROUND: The DOD PKI PMO has discovered problems building certificate chains when the DoD Root and Intermediate certificates have not been properly installed. PROBLEM: Administrators must install the DoD Root and latest intermediate CA certificates on all workstations and servers. SYMPTOMS: Users can experience delays when performing operations with DoD PKI issued certificates. Inconsistent path building can occur where DoD PKI certificates chain up to the Common Policy root or cross-certificates mentioned below. CERTIFICATES: Thumbprint Issuer/Subject dc92f91bab283472023b32178504e19bf7d9a94c Iss: OU=Entrust, OU=FBCA Sub: OU=Entrust, OU=FBCA 0a0e46657f4148df2d1c6778ea9308a8ca41989f Iss: CN=Common Policy, OU=FBCA Sub: OU=Entrust, OU=FBCA 3bae7b920ee6616755be4fa287777eef2f6b33f6 Iss: CN=Common Policy, OU=FBCA Sub: OU=Entrust, OU=FBCA dc92f91bab283472023b32178504e19bf7d9a94c Iss: OU=Entrust, OU=FBCA Sub: CN=DoD Interoperability Root CA 1 eea68fc8701e41e6429a341ae4162bbda634f7f4 Iss: CN=DoD Interoperability Root CA 1 Sub: CN=DoD Root CA 2 RESOLUTION: * Disable the Microsoft Root Update Service (DISA STIG requirement) * Install the DoD Root and Intermediate CA certificates which can be done by running the latest version of InstallRoot (as an administrator). InstallRoot can be obtained from https://www.dodpke.com/installroot/ * Run this tool. DEPENDENCIES: * Microsoft Windows 2000 SP3 or newer Operating System * .NET Framework 2.0 or above USAGE: /COMMONPOLICY Additionally removes the Common Policy self-signed certificates /S Silent mode - doesn't require user to hit <ENTER>. NOTE: Administrative privileges are required to remove certificates from the LocalMachine store. Starting to search for certificates... Searching the LocalMachine Root certificate store...certificates not found. Searching the LocalMachine CA certificate store...certificates not found. Searching the LocalMachine My certificate store...certificates not found. Searching the CurrentUser Root certificate store...certificates not found. Searching the CurrentUser CA certificate store...certificates not found. Searching the CurrentUser My certificate store...certificates not found. Finished. Certs were found and removed: ##### FBCA cross-certificate removal tool ##### Created by DoD PKE Engineering January 2010 BACKGROUND: The DOD PKI PMO has discovered problems building certificate chains when the DoD Root and Intermediate certificates have not been properly installed. PROBLEM: Administrators must install the DoD Root and latest intermediate CA certificates on all workstations and servers. SYMPTOMS: Users can experience delays when performing operations with DoD PKI issued certificates. Inconsistent path building can occur where DoD PKI certificates chain up to the Common Policy root or cross-certificates mentioned below. CERTIFICATES: Thumbprint Issuer/Subject dc92f91bab283472023b32178504e19bf7d9a94c Iss: OU=Entrust, OU=FBCA Sub: OU=Entrust, OU=FBCA 0a0e46657f4148df2d1c6778ea9308a8ca41989f Iss: CN=Common Policy, OU=FBCA Sub: OU=Entrust, OU=FBCA 3bae7b920ee6616755be4fa287777eef2f6b33f6 Iss: CN=Common Policy, OU=FBCA Sub: OU=Entrust, OU=FBCA dc92f91bab283472023b32178504e19bf7d9a94c Iss: OU=Entrust, OU=FBCA Sub: CN=DoD Interoperability Root CA 1 eea68fc8701e41e6429a341ae4162bbda634f7f4 Iss: CN=DoD Interoperability Root CA 1 Sub: CN=DoD Root CA 2 RESOLUTION: * Disable the Microsoft Root Update Service (DISA STIG requirement) * Install the DoD Root and Intermediate CA certificates which can be done by running the latest version of InstallRoot (as an administrator). InstallRoot can be obtained from https://www.dodpke.com/installroot/ * Run this tool. DEPENDENCIES: * Microsoft Windows 2000 SP3 or newer Operating System * .NET Framework 2.0 or above USAGE: /COMMONPOLICY Additionally removes the Common Policy self-signed certificates /S Silent mode - doesn't require user to hit <ENTER>. NOTE: Administrative privileges are required to remove certificates from the LocalMachine store. Starting to search for certificates... Searching the LocalMachine Root certificate store... * FOUND Certificate: CN=Common Policy, OU=FBCA, O=U.S. Government, C=us Issuer : CN=Common Policy, OU=FBCA, O=U.S. Government, C=us Thumbprint : CB44A097857C45FA187ED952086CB9841F2D51B5 Serial: 293647AAE38AAC864A2356F2CAB761AF - Removing Certificate...SUCCESSFUL * FOUND Certificate: CN=Common Policy, OU=FBCA, O=U.S. Government, C=us Issuer : CN=Common Policy, OU=FBCA, O=U.S. Government, C=us Thumbprint : 76B76096DD145629AC7585D37063C1BC47861C8B Serial: 39E3815404C50AB247EFFEF336CFC698 - Removing Certificate...SUCCESSFUL Searching the LocalMachine CA certificate store...certificates not found. Searching the LocalMachine My certificate store...certificates not found. Searching the CurrentUser Root certificate store...certificates not found. Searching the CurrentUser CA certificate store...certificates not found. Searching the CurrentUser My certificate store...certificates not found. Finished. The second log file will be named after the host followed by " _WXP-03-Uninst-Updt-Rt-Cert-Comp.txt" If the host is running Windows XP or Server 2003, the Windows Component will be removed, and the following information will be logged. If the host is running Vista or above, the file will be blank. 401.339.0: 0x80070002 (WIN32: 2) 401.432.0: 0x80070002 (WIN32: 2) 401.1246.0: 0x80070002 (WIN32: 2): C:\WINDOWS\CAPolicy.inf 104.685.0: 0xe0000102 (INF: -536870654): Components 110.379.0: 0xe0000102 (INF: -536870654) 104.1282.0: 0xe0000102 (INF: -536870654) 104.2445.0: 0xe0000102 (INF: -536870654) 104.2436.0: 0xe0000102 (INF: -536870654) 104.2482.0: 0xe0000102 (INF: -536870654) 104.2482.0: 0xe0000102 (INF: -536870654) 104.2482.0: 0xe0000102 (INF: -536870654) 104.2587.0: 0xe0000102 (INF: -536870654) 104.2587.0: 0xe0000102 (INF: -536870654) 104.2587.0: 0xe0000102 (INF: -536870654) 104.2502.0: 0xe0000102 (INF: -536870654) 104.2502.0: 0xe0000102 (INF: -536870654) 104.2502.0: 0xe0000102 (INF: -536870654) The script will run one time, if the log files it creates remain present for subsequent logons. The script will not run if the domain is unavailable at boot. During logon when the script is working, the startup may take longer than usual. This should be a onetime occurrence to repair this issue. Problem: DisableRootAutoUpdate set to Enabled by doesn't seem to work for this case. Users are still finding their systems are being updated automatically with the "Common Policy Root CA" certificate.

Hi, Thanks for posting in Microsoft TechNet forums. Do you enable the DisableRootCertificateUpdates through the following Group Policy? Administrative Templates/System/Internet Communication Management/Internet Communication settings/Turn off Automatic Root Certificates Update If it is the case, try to enable it through the following registry value: Key: HKLM\Software\Policies\Microsoft\SystemCertificates\AuthRoot Value: DisableRootAutoUpdate Type: REG_DWORD Data: 0 - Root Update enabled; 1 - Root Update disabled Important Caution: please backup your registry before modifying it, any incorrect modification can cause unrecoverable damage. Best Regards Dale Qiao TechNet Subscriber Support in forum. If you have any feedback on our support, please contact tngfb@microsoft.com

Ok, I'll try that and get back to you in a few days. Thanks!

No luck, it was already set to 1. Any other suggestions? Thanks, Rob

Try modify the Intended Purposes of the Common Policy root CA cert on all DCs and set the policy to disable the 3rd Party Trusted Root store. Any roots that need to be trusted by the organization will need to be published to Active Directory. Best Regards Dale Qiao TechNet Subscriber Support in forum. If you have any feedback on our support, please contact tngfb@microsoft.com

Hi, As this thread has been quiet for a while, we assume that the issue has been resolved. At this time, we will mark it as ‘Answered’ as the previous steps should be helpful for many similar scenarios. If the issue still persists, please feel free to reply this post directly so we will be notified to follow it up. You can also choose to unmark the answer as you wish. BTW, we’d love to hear your feedback about the solution. By sharing your experience you can help other community members facing similar problems. Thanks for your understanding and efforts. Best Regards Dale

This definitely has NOT solved our issue. We have two goals: 1. We want to figure out how, and where this is coming from, as it seems to be automatic, and is by-passing the supposed controls to block this function. 2. We want a permanent fix to stop this action from happening completely, not a Band-Aid to block it when it happens. Is it possible for you to esculate this issue? In talking with our different organizations, we understand that many DoD Agencies and Organizataions have tickets in with Microsoft regarding this issue. This is a major issue for us, and we need resolution immediately. Thanks, Rob

We have found the solution above as only a temporary fix. We have this problem on DOD builds of Vista ENT SP2 and XP SP3. 1. If users outside the domain send one of the "bad" certificates the problem starts over for the recipient. 2. If a user in your domain has an old email or contact with the Entrust certificate and forwards or replies it you will again have the "bad" certificates. 3. This fix only works for the currently logged in user profile, so if another profile on the machine has the "bad" certificates you are back where you started. It still resides on the EXCH server in the emails and contacts. 4. We still have commercial web sites that need these certificates to work properly so now what? The real fix is for the always behind the times tech DOD to fix their certificate.

I completely agree the first post is only a temporary fix. We have also seen the issues to discribed, and that the "bad" cert is reinstalled to recipents, when users with the "bad" cert installed send mail to clean users. Tell me more about the commercial websites you're having issues with, and needing these certs to work properly? The fix for us is for Microsoft to tell us how to block this auto install of these certificates.

This issue still has not been fixed...